PATENT 

REMARKS 

Claims 1-67 are pending in the application. 
Claims 1-67 have been rejected. 

Claims 1, 8, 12, 13, 15, 19, and 38 have been amended. No new matter has been 

added. 

Claims 4, 18, and 28-37 have been cancelled. 

Rejection of Claims under 35 U.S.C. §1 02(b) 
Claims 1-20, 22-31, 33-38, 40-48, 50-58, and 60-67 stand rejected under 35 
U.S.C. § 102(b) as being anticipated by Beck et al. (USPPN 2001/0014097) ("Beck"). 
Applicants respectfully traverse this rejection. 

With respect to amended claim 1, the cited art fails to teach or suggest a network 
device that is configured to append a header, which identifies the port of that network 
device that received a particular packet, to that packet before sending the packet to a 
virtual network device. In the rejection of claim 4 in the Non-Final Office Action mailed 
December 7, 2007 (hereinafter NFOA), paragraphs 9 and 40 of Beck were cited as 
teaching this feature. However, these paragraphs merely describe how receiving 
applications can listen to particular software ports (paragraph 40) and how a processor 
node can modify a packet header to identify the network address of another processor 
node (paragraph 9) in order to be able to transfer that packet to the other processor node. 
Nothing in either paragraph teaches or suggests appending a packet header to a packet to 
identify a port that received the packet, prior to sending that packet to another device. At 
best, Beck simply describes modifying a packet header to indicate a new destination to 
which the packet should be sent, not appending a packet header to a packet to indicate the 
interface that received the packet. 

In response to the above arguments, the Final Office Action mailed June 13, 2008 
(hereinafter FOA) states that paragraph 9 of Beck teaches "modifying (i.e., appending) a 
header with information and directing the packet to the destination processor node." 
FOA, p. 15. However, this response does not explain how Beck purportedly teaches the 
particular type of header recited in claim 1 . As noted above, Beck' s header is modified to 
indicate a destination to which the packet should be sent . In contrast, claim 1 describes a 
header that identifies the port at which the packet was received . Thus, Beck's header is 
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used to send a packet to a destination, while claim l's header is used to identify a port 
that has already received the packet. Given this clear distinction, Beck neither teaches nor 
suggests the features of claim 1. 

For at least the foregoing reason, claim 1 is patentable over the cited art. Claims 
2-3 and 4-7 are patentable over the cited art for similar reasons. 

With respect to claim 38, the cited art fails to teach or suggest sending a first 
packet via a first link of a virtual link bundle if a destination identifier associated with the 
first packet identifies the virtual link bundle; and sending a second packet via a second 
link of the virtual link bundle if a destination identifier associated with the second packet 
identifies the virtual link bundle, where a single network device performs both the 
sending the first packet and the sending the second packet, the first link is coupled to a 
first virtual network device sub-unit, and the second link is coupled to a second virtual 
network device sub-unit. 

The FOA cites paragraph 9 of Beck as teaching sending two different packets via 
two different links in a virtual link bundle. FOA, p. 10. Paragraph 9, at best, describes 
how one processor node can retransmit a data packet to another processor node. Nothing 
in paragraph 9 teaches or suggests that there are two possible links that can be used to 
send packets associated with the same destination identifier. Additionally, paragraph 9 
fails to teach or suggest using each of two such links to send different packets, in 
response to those packets being associated with the same destination identifier. 

For at least the foregoing reasons, claim 38 is patentable over the cited art, as are 
its dependent claims 39-40. Claims 48-50 and 58-60 are patentable over the cited art for 
similar reasons. 

With respect to claim 41, the cited art fails to teach or suggest filtering a packet 
from a packet flow being sent via the first interface if the packet was received via a 
virtual network device link. The Examiner cites paragraph 9 of Beck as teaching this 
feature, characterizing the cited portion of Beck as teaching "When a receiving node 
determines which processor node to send to, it broadcasts the data packet over the 
network for delivery to the processor node." NFOA, p. 17. Applicants respectfully 
submit that the act of broadcasting clearly neither teaches nor suggests "filtering" a 
packet from a packet flow being sent via a particular interface. Instead, "broadcasting" 
suggests sending one or more copies of the packet, via all available interfaces. 
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Furthermore, nothing in NFOA or the cited paragraph of Beck teaches or suggests 
performing the act of filtering in response to a packet being received via a virtual network 
device link (in fact, no portion of Beck has been cited as teaching such a virtual network 
device link). 

In response, the FOA characterizes Beck's paragraph 9 as teaching that: "A 
processor node receives a packet (i.e., via a virtual network device link, see fig. 2) and 
decides where to send it. In this way the packet is filtered." FOA, p. 16. However, 
deciding where to send a packet neither teaches nor suggests filtering a packet from a 
packet flow being sent via a particular interface. Filtering a packet from a packet flow 
removes the packet from that flow. See e.g. paragraph 59 of the specification. Deciding 
where to send a packet would, at best, appear to cause a packet to be added to a flow, not 
remove a packet from a flow. As such, Beck's paragraph 9 clearly fails to teach or 
suggest filtering a packet from a flow being output via an interface. Furthermore, Beck's 
paragraph 9 also fails to teach or suggest selectively filtering a packet from a flow based 
upon whether the packet was received via a virtual network device link. 

For at least the foregoing reasons, claim 41 is patentable over the cited art, as are 
its dependent claims 42-47. Claims 8-17, 18-27, 51-57, and 61-67 are patentable over the 
cited art for similar reasons. 

Rejection of Claims under 35 U.S.C. §103(a) 
Claims 21, 32, 39, 49 and 59 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Beck in view of Mankude et al. (USPN 6,735,205) ("Mankude"). 
Applicants respectfully traverse this rejection for the reasons similar to those set forth 
above. 
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CONCLUSION 

In view of the amendments and remarks set forth herein, the application and the 
claims therein are believed to be in condition for allowance without any further 
examination and a notice to that effect is solicited. Nonetheless, should any issues 
remain that might be subject to resolution through a telephone interview, the Examiner is 
invited to telephone the undersigned at 512-439-5087. 

If any extensions of time under 37 C.F.R. § 1.136(a) are required in order for this 
submission to be considered timely, Applicant hereby petitions for such extensions. 
Applicant also hereby authorizes that any fees due for such extensions or any other fee 
associated with this submission, as specified in 37 C.F.R. § 1.16 or § 1.17, be charged to 
deposit account 502306. 



Respectfully submitted, 

/Brenna A. Brock/ 

Brenna A. Brock 
Attorney for Applicants 
Reg. No. 48,509 
Telephone: (512) 439-5087 
Facsimile: (512)439-5099 
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